Test Web

A private Web site, set up specifically for testing. Because you don't want to expose your work to the public until it's been thoroughly tested and corrected, we recommend that all new development and testing occur on a separate Web site, called a test Web. You can isolate this site from general scrutiny by assigning it to a non-default IP Port address (that is, to a number other than 80), and by controlling access to the site's URL.

W3E References:

beta test

production Web

IP port address

URL

Web site

WebMaster

Web server

Detail:

It's always a good idea to test your CGI applications, and any modifications to your HTML documents in a test Web. This lets you tweak your CGIs unobtrusively and play around with the look and feel of your pages to your heart's content, without exposing yourself to public scrutiny.

Modifying CGI applications that can affect your production Web can be dangerous and painful. That's because introducing errors into a production Web can cause your CGI-dependent forms to fail or work improperly. This could easily confuse your users; worse still, it could cause them to write your site off as "flaky" and drive them away.

We've learned from personal experience that almost all unhappy users will turn in Web comment forms with objections, complaints, and negative feedback, compared to the unusual few who send compliments. If you develop your CGI applications and tweak your pages out of your users' sight, you can avoid many of the causes of unhappiness. This is where a test Web comes in really handy.

What is a test Web?

A test Web should be a private Web site that exhibits the same behavior and structure as your production Web, but isn't publicly accessible. Regardless of your Web server's operating system, the best way to test CGI applications and HTML documents is to create and modify them in your test Web. Only when they pass your tests, and survive the onslaught of your beta testers, should you even consider installing them on your production Web.

If you can't install a test server yourself, ask your local WebMaster for help. If your server already has a testing area, use that. If not, set up a personal CGI directory where only you (and your beta testers) have permission to execute the CGI programs and access the Web pages it contains. Either way, you'll find a good place to test things before they're released to the whole wide world.

Setting up a test Web

Setting up a test Web is easier than you might imagine. Jay Weber at EIT has created a forms-based "Webmaster Starter Kit" that builds a UNIX-based Web server for you. It's as easy as filling out the forms; for more information, please visit this URL: Webmaster Starter Kit

This service requires no root access or privileges on your target system, making it easy to install a test Web with minimal effort. The only requirement you'll want to adhere to absolutely is to establish a different IP Port address for your test Web's HTTP listener process. (By rule, this must be a number greater than 1024; because 80 is the default IP Web listener port, 8000 range addresses are a common choice). A typical port number of a test server is 8001. Thus, the URL for a test Web would look something like: http://xyzcorp.com:8001/test/

(Note: This is not a real URL, so please don't try to access it; you might stumble across somebody else's test Web by accident!).

Populating your test Web

Once you've successfully installed your test Web, you'll want to mirror those portions of your production Web that you'll be working on. In English, this means the following:

1. Copy all the relevant files (and subdirectories, for CGIs and graphics, if that's how your production Web site is set up) to the test Web directories. Here, "relevant files" means stuff you'll be working on or changing.
2. Use symbolic links or aliases to point to other elements that won't be changed in your production Web. This will protect you from accidentally making changes that otherwise wouldn't be reflected in your production Web later.
3. Edit your BASE URL and other relative references in your HTML documents to point to the new test Web's URL. (If you're smart, this will involve only a few changes, or perhaps only one change: to the BASE URL statement in your test Web's home page).
4. Change the 'DocumentRoot' definition for the test server; this usually consists of a path specification to point the HTTP software at the root of your test Web's directory structure, and works much the same way as changing the BASE URL in your home page.

Using your test Web

Once you've set up your test Web, and have installed the files you want to alter or operate on, you can make whatever changes you like. Just remember, you'll want to test your own work thoroughly after you think you're done. After that, you'll want to invite at least a handful of dedicated beta testers to bash on your site and help you find mistakes, omissions, misspellings, and other potential gotchas. Be sure to point them at any CGI programs you've altered, and make sure they exercise these thoroughly: they're the most common culprits when it comes to problems, failure, or errors. Bash them thoroughly before considering your job complete!

Reintegrating the new stuff from test to production Web

When you're convinced that your changes and new programs are working, only then should you consider installing them on your production Web. To do that, you'll want to copy all the changed files into their respective production locations:

1. Changed or new HTML documents into the root directory for the production Web (or wherever else you keep them)
2. Changed or new graphics into the graphics directory for your production Web. (We keep ours in a subdirectory called /graphics).
3. Changed or new CGI programs into the /cgi-bin directory on your production Web server (or wherever else your Webmaster tells you to put them; please check beforehand!)
4. After you've installed the new stuff, perform another set of tests to make sure the change of location hasn't affected the site's performance. If you're using relative URLs and a directory structure that duplicates the production Web on your test Web, this step should go without a hitch. Nevertheless, the adage you learned in math class holds double here: "Always check your work!"

At this point, your changes should be integrated and your users should be able to marvel at the improvements and new material, without stumbling over unfixed mistakes or discovering bizarre CGI behaviors.